fix: clean up failed Skill Card attachments - #3614
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
@SebTardif is attempting to deploy a commit to the OpenClaw Foundation Team on Vercel. A member of the Team first needs to authorize it. |
|
Codex review: needs maintainer review before merge. Reviewed September 15, 2026, 11:49 PM ET / September 16, 2026, 03:49 UTC (Revision 3). ClawSweeper reviewWhat this changesDelete newly generated Skill Card files when attachment fails, with regression coverage and documentation preserving successful cards and historical fingerprints. Merge readiness✅ Ready for maintainer review This PR remains necessary: current main still leaks newly stored cards when attachment rejects. No blocking findings remain, and the updated local Convex evidence addresses the previous proof request. Priority: P2 Review scores
Verification
How this fits togetherClawHub’s Skill Card worker submits generated Markdown to a Convex action, which stores it and attaches it to a skill version. Attached cards become available through the catalog’s HTTP endpoint and Skill Card tab. flowchart TD
A[Worker submits Markdown] --> B[Validate worker and content]
B --> C[Store new card]
C --> D{Attachment succeeds?}
D -->|Yes| E[Retain card and fingerprints]
E --> F[HTTP endpoint and catalog page]
D -->|No| G[Delete new blob and preserve error]
Before mergeNone. Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Technical reviewBest possible solution: Keep cleanup with the action that allocates each card, preserving attachment errors and existing card and fingerprint retention. Do we have a high-confidence way to reproduce the issue? Yes, from source: main stores a blob before a mutation that rejects stale leases or unavailable versions, with no cleanup. This review did not execute a current-main reproduction. Is this the best way to solve the issue? Yes—the allocating action is the narrowest repair location and matches the existing upload cleanup pattern. Moving cleanup into the external worker would lose access to the newly allocated storage ID. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 7406f65e792f. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
History |
Delete only the new card blob when attachment rejects, preserve the original failure, and retain successful cards and historical fingerprints. Prove storage contents through registered Convex fixtures and the real local-auth publish lifecycle. Co-authored-by: Sebastien Tardif <SebTardif@ncf.ca>
2d28ce6 to
e8795ff
Compare
Ref #3674.
What Problem This Solves
Fixes generated Skill Card blobs being left in storage when attachment rejects a stale worker lease or an unavailable skill version.
User Impact
Failed attachments clean up their newly generated blob. Successfully attached cards, earlier card blobs, and historical bundle fingerprints remain available.
Why This Change Was Made
The completion action owns the newly stored blob until the attachment mutation succeeds. A rejected mutation now triggers cleanup of that blob only, while retaining the original attachment error if cleanup also fails.
Evidence
bun run ci:prpassed before the main refresh, including 6,894 coverage tests, package verification, types/build, and HTTP integration. After rebasing, the 17 focused tests, full static gate, and full types/build gate passed again.